Obfuscation of function block diagrams

Obfuscation is a process of transforming a program into an equivalent version which is harder to understand and reverse-engineer. Little attention has been paid to obfuscation techniques for programs written for programmable logic controllers (PLC). However, there is no reason to assume that an attacker would not be interested in hiding malicious payload into a PLC program before it is compiled to machine code.In this paper, I present five techniques for obfuscating IEC 61131-3 Function Block Diagram (FBD) programs. Four of the techniques are specific to the graphical representation of FBD. I then evaluate the applicability of each technique by experimenting with different PLC programming tools. I prove that at least four of the techniques are practically applicable, and demonstrate features that some tools successfully use to prevent abuse. Stricter rules, if implemented in IEC 61131-3, would prevent some of the techniques listed

Obfuscation of function block diagrams

Obfuscation is a process of transforming a program into an equivalent version which is harder to understand and reverse-engineer. Little attention has been paid to obfuscation techniques for programs written for programmable logic controllers (PLC). However, there is no reason to assume that an attacker would not be interested in hiding malicious payload into a PLC program before it is compiled to machine code.In this paper, I present five techniques for obfuscating IEC 61131-3 Function Block Diagram (FBD) programs. Four of the techniques are specific to the graphical representation of FBD. I then evaluate the applicability of each technique by experimenting with different PLC programming tools. I prove that at least four of the techniques are practically applicable, and demonstrate features that some tools successfully use to prevent abuse. Stricter rules, if implemented in IEC 61131-3, would prevent some of the techniques listed

Model-Checking I&C Logics — Practical Examples

A spurious actuation of an instrumentation and control (I&C) system function is an illustrative example of a "negative"' requirement being violated. Verifying such requirements with testing is very hard. Model checking is a formal verification method, aimed at mathematical proof that a (system) model fulfills stated formal properties. Due to the exhaustive coverage, design issues are found in I&C systems already subjected to, e.g., testing. The formal properties can also address the absence of unwanted functionality—spurious signals, contradictory commands, frozen outputs, etc.In this paper, we discuss the use of model checking the Finnish nuclear industry, where the method has been applied in different plant life-cycle phases. In the Olkiluoto 3 newbuild and Loviisa 1&2 renewal projects, the focus was on detailed logic design. In the Hanhikivi 1 newbuild and Olkiluoto 1&2 I&C renewal projects, we instead verified functional diagrams, developed early in the projects as input for the later detailed design stages.Through two practical examples of design issues identified in these projects, we demonstrate how easy it is to disprove "negative" requirements having to do with contradictory signals. We also demonstrate how to filter out irrelevant counterexamples, to find out other types of problematic scenarios, even if the first one returned by the model checker can otherwise be ruled out

Analyzing Defense-in-Depth Properties of Nuclear Power Plant Instrumentation and Control System Architectures Using Ontologies

The overall instrumentation and control (I&C) architecture of a nuclear power plant (NPP) is comprised of several I&C systems and their dependencies. The architecture needs to fulfil the principle of defense in depth (DiD). Defense-in-depth is the principal method for preventing accidents and mitigating the potential consequences of accidents. The levels of DiD should be independent of each other. The primary means to achieve independence are diversity, physical separation, and functional isolation. Approaches with extensive tool support for ensuring that the design solutions of nuclear overall I&C architectures realize relevant DiD properties are scarce. An ontology of the semantic web is a specification of a representational vocabulary for a shared domain of discourse, containing definitions of classes, individuals, and their relationships. An ontology-based knowledge base, built on named graphs, enables a computer to combine pieces of information into valuable knowledge based on queries. In this paper, we present an ontology-based approach for assessing that an NPP I&C architecture fulfils different DiD properties. In our approach, we aim at checking requirements related to physical separation, electrical isolation, communication independence, diversity, safety classification, and failure tolerance. We also discuss the developed work process and tool chain for ontology-based analysis. We demonstrate the use of the ontology and the work process based on two case studies

Using model checking for interlocking software verification

The application of different verification methods is a prominent part of the development process for safety related systems. Some methods are suitable for the early lifecycle phases, while others are best used later. In the end, the most significant thing is that all the lifecycle phases can be verified in a sufficient manner and using the method best suited for the purpose. At Mipro, we have found that formal verification increases diversity in order to achieve the best possible verification results and improve the quality and safety of the deliveries